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REMARKS 

Reconsideration and allowance of the subject application are respectfully requested. 

Amendments have been made to the claims so that a mobile packet flow in claim 1 , for 
example, is now refers to mobile user data packet flow to distinguish from call set-up signaling. 
Also, language is included to specify that the middlebox(es) are in an IP-based user plane while 
the midcom agent is in a control plane that is separate from the IP-based user plane. Example 
support may be found in Figure 2 and related text in the specification. 

Claims 1 , 2, 4-10 and 12 stand rejected under 35 USC §103 as being obvious based on 
Mitchell and newly-applied Das. This rejection is respectfully traversed. 

Mitchell describes discovering and registering middleboxes in response to a call set-up 
message. Knowing the identities of the middleboxes, a middlebox control node can signal to the 
middleboxes appropriate orders so that the middleboxes can perform required tasks. On page 20 
of the office action, the Examiner opines that even though Michell lacks a teaching of 
registration at a midcom agent (mapped onto call servers 1 8 in Figure 6) or at middleboxes 
(mapped onto middleboxes 10, 11), Mitchell "clearly discloses that once middlebox 1 receives a 
call set-up request from the terminal [A], by adding its own identity to the call set-up message 
and forwards it to the call server (thus, adding identity and forwarding to a server is in a sense 
registering oneself). In addition, the call server then instructs the middlebox 1 to set up a binding 
(i.e. a control message) (see par [0062])." The binding referred to in [0062] is that the 
middlebox is requested by the call server to set up a voice packet path from terminal A and in 
response replies with a public address and port to which packets from terminal B to terminal A 
should be sent. 
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The Examiner admits that Mitchell lacks a teaching of "registration at midcom agent" 
and applies Das which teaches a mobile registering with a foreign agent so the foreign agent can 
be used as a care-of address for sending packets to the mobile or the mobile can use a collocated 
address to register with it home agent using mobile IP registration. It appears that the Examiner 
is likening the midcom agent with the foreign or home agent. Clarification is requested. 

The rejection is based on a faulty assumption: that a call set-up message from terminal A 
to middlebox 1 and from middlebox 1 to the call server 1 8 (midcom agent) in Mitchell can be 
mapped to the claimed mobile user data packet flow. As shown in the non-limiting example in 
Figure 2 of Applicants' application, the mobile user data flow in thick lines is different from the 
IP control signaling and the session signaling. The call/session set-up messages are sent using 
the IP control signaling and the session signaling. As reflected in the amended claims, a mobile 
user data packet flow in the user plane is different from and cannot be mapped to session set up 
messages sent in the control plane with IP layer control signaling and/or session layer control 
signaling. 

Mitchell is concerned with discovering and registering middleboxes in response to a call 
set-up message. But the data flow/bearer B in Mitchell does not register its presence in each 
middle box as recited in step b of claim 1 : "each mobile user data packet flow registering its 
presence in each middlebox it encounters on its way from its source to its destination in the IP 
based user plane." In fact, the bearer connection B, which Applicants believe corresponds to the 
user data flow between the middleboxes 1 and 2 and users A and B in Figure 6, is not described 
in much detail by Mitchell outside of paragraph [0046]. Ultimately, Mitchell does not disclose 
how middlebox registration handles mobile user data packet flows. 
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Mitchell and Das do not teach step c in claim 1 : "in response to step b, each middlebox 
in the IP based user plane registering itself and the identities of mobile user data packet flows it 
handles in the IP based user plane at a midcom agent in the common, IP-based control plane 
using an extended midcom signalling protocol." The mobile packet flow identities bind each 
flow and a specific control process in the midcom agent. 

Mitchell and Das do not teach registering mobile user data flows that move between 
different middleboxes so that movement of a mobile terminal or a moving network can be 
acconlmodated. In claim 1 , registering the mobile user data flow identities at a midcom agent 
together with the identity of the middlebox that the flow traverses allows the flow to be bound to 
a specific flow control process in the midcom agent even though the flow may move between 
different middleboxes during a call. 

The application is in condition for allowance. An early notice to that effect is earnestly 
solicited. 

Respectfiilly submitted, 
NIXON & VANDERHYE P.C. 
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